Software  Engineering  Institute 


Data  Rights  for  Proprietary  Software 
Used  in  DoD  Programs 


Julie  Cohen 

Bonnie  Troup  (The  Aerospace  Corporation) 
Henry  Ouyang  (The  Aerospace  Corporation) 


April  2010 

TECHNICAL  NOTE 

CMU/SEI-201 0-TN-01 4 


Acquisition  Support  Program 

Unlimited  distribution  subject  to  the  copyright. 


http://www.sei.cmu.edu 


Carnegie  Mellon 


This  report  was  prepared  for  the 


SEI  Administrative  Agent 
ESC/XPK 
5  Eglin  Street 

Hanscom  AFB,  MA  01731-2100 

The  ideas  and  findings  in  this  report  should  not  be  construed  as  an  official  DoD  position.  It  is  published  in  the 
interest  of  scientific  and  technical  information  exchange. 

This  work  is  sponsored  by  the  U.S.  Department  of  Defense.  The  Software  Engineering  Institute  is  a  federally 
funded  research  and  development  center  sponsored  by  the  U.S.  Department  of  Defense. 

Copyright  2010  Carnegie  Mellon  University. 

NO  WARRANTY 

THIS  CARNEGIE  MELLON  UNIVERSITY  AND  SOFTWARE  ENGINEERING  INSTITUTE  MATERIAL  IS 
FURNISHED  ON  AN  "AS-IS"  BASIS.  CARNEGIE  MELLON  UNIVERSITY  MAKES  NO  WARRANTIES  OF 
ANY  KIND.  EITHER  EXPRESSED  OR  IMPLIED,  AS  TO  ANY  MATTER  INCLUDING,  BUT  NOT  LIMITED 
TO,  WARRANTY  OF  FITNESS  FOR  PURPOSE  OR  MERCHANTABILITY,  EXCLUSIVITY,  OR  RESULTS 
OBTAINED  FROM  USE  OF  THE  MATERIAL.  CARNEGIE  MELLON  UNIVERSITY  DOES  NOT  MAKE 
ANY  WARRANTY  OF  ANY  KIND  WITH  RESPECT  TO  FREEDOM  FROM  PATENT,  TRADEMARK,  OR 
COPYRIGHT  INFRINGEMENT. 

Use  of  any  trademarks  in  this  report  is  not  intended  in  any  way  to  infringe  on  the  rights  of  the  trademark  holder. 

Internal  use.  Permission  to  reproduce  this  document  and  to  prepare  derivative  works  from  this  document  for  inter¬ 
nal  use  is  granted,  provided  the  copyright  and  "No  Warranty"  statements  are  included  with  all  reproductions  and 
derivative  works. 

External  use.  This  document  may  be  reproduced  in  its  entirety,  without  modification,  and  freely  distributed  in 
written  or  electronic  form  without  requesting  formal  permission.  Permission  is  required  for  any  other  external 
and/or  commercial  use.  Requests  for  permission  should  be  directed  to  the  Software  Engineering  Institute  at 
permission  @  sei.cmu.edu. 

This  work  was  created  in  the  performance  of  Federal  Government  Contract  Number  FA8721-05-C-0003  with 
Carnegie  Mellon  University  for  the  operation  of  the  Software  Engineering  Institute,  a  federally  funded  research 
and  development  center.  The  Government  of  the  United  States  has  a  royalty-free  government-purpose  license  to 
use,  duplicate,  or  disclose  the  work,  in  whole  or  in  part  and  in  any  manner,  and  to  have  or  permit  others  to  do  so, 
for  government  purposes  pursuant  to  the  copyright  license  under  the  clause  at  252.227-7013. 

For  information  about  purchasing  paper  copies  of  SEI  reports,  please  visit  the  publications  section  of  our  website 
(http://www.sei.cmu.edu/publications/). 


Table  of  Contents 


Acknowledgments  vii 

About  This  Report  ix 

Abstract  xi 

1  Introduction  1 

2  Terminology  3 

2.1  Software  Categories  3 

2.1.1  Commercial  Off-The-Shelf  Component  3 

2.1.2  Commercial  Item  3 

2.1 .3  Proprietary  Software  (Developed  at  Private  Expense)  4 

2.1 .4  Software  Developed  at  the  DoD’s  Expense  5 

2.1.5  Restricted  Computer  Software  5 

2.2  Categories  of  Data  Rights  5 

2.2.1  Limited  Rights  6 

2.2.2  Unlimited  Rights  6 

2.2.3  Government  Purpose  Rights  7 

2.2.4  Restricted  Rights  7 

2.2.5  Specially  Negotiated  Rights  8 

2.2.6  DoD  Policy  9 

3  Data  Rights  Risk  Analysis  11 

3.1  TMOS  Experience  11 

3.2  Space  Segment  Experience  12 

3.3  General  Guidance  12 

3.4  Lessons  Learned  12 

4  Data  Rights  Definition  Development  13 

4.1  TMOS  Experience  13 

4.1.1  TMOS  Data  Sets  13 

4.1.2  TMOS  User  Groups  16 

4.2  Space  Segment  Experience:  17 

4.2.2  TSAT  Space  Segment  User  Groups  19 

4.3  Sample  Data  Set  Format  20 

4.4  General  Guidance  20 

4.4.1  DataSets  20 

4.4.2  User  Groups  21 

4.5  Lessons  Learned  21 

5  TMOS  Data  Rights  Options  22 

5.1  TMOS  Experience  22 

5.1.1  Development  Data  Options  22 

5.1.2  Sustainment  Data  Options  23 

5.1.3  Interoperability  Data  Options  23 

5.1.4  Deployment  Data  Options  24 

5.2  Space  Segment  Experience  24 

5.3  General  Guidance  26 

5.4  Lessons  Learned  26 


i  |  CMU/SEI-2010-TN-014 


6 

Other  Data  Rights-Related  Issues 

29 

6.1 

TMOS  Experience 

29 

6.2 

Space  Segment  Experience 

29 

6.3 

General  Guidance 

29 

6.3.1  Non-Modified  COTS 

29 

6.3.2  Government  Off-The-Shelf  (GOTS) 

29 

6.3.3  Open  Source  Software  (OSS) 

30 

6.4 

Lessons  Learned 

30 

7 

GPS 

Data  Rights 

31 

7.1 

Approach 

31 

7.2 

General  Guidance 

31 

7.3 

Lessons  Learned 

31 

8 

Risk 

Ratings 

32 

8.1 

TMOS  Experience 

32 

8.2 

Space  Segment  Experience 

34 

8.3 

General  Guidance 

34 

8.4 

Lessons  Learned 

34 

9 

Contract  Clauses 

36 

9.1 

TMOS  Experience 

36 

9.2 

Space  Segment  Experience 

36 

9.3 

GPS  Experience 

36 

9.4 

General  Guidance 

37 

9.5 

Lessons  Learned 

37 

10 

Conclusion 

38 

11 

Useful  Sources 

39 

References/Bibliography  41 


ii  |  CMU/SEI-2010-TN-014 


List  of  Figures 

Figure  1 :  Data  Options  Risk  Matrix  32 


iii  |  CMU/SEI-2010-TN-014 


|  CMU/SEI-2010-TN-014 


List  of  Tables 


Table  1 : 

Sample  Data  Set  Format 

20 

Table  2: 

TMOS  Development  Data  Options 

23 

Table  3: 

Sustainment  Data  Options 

23 

Table  4: 

Interoperability  Data  Options 

24 

Table  5: 

Alternate  Deployment  Data  Options  View 

27 

Table  6: 

Combined  Options  View 

28 

Table  7: 

TMOS  Selected  Options 

33 

Table  8: 

Useful  Sources 

39 

v  I  CMU/SEI-201 0-TN-01 4 


vi  |  CMU/SEI-2010-TN-014 


Acknowledgments 


The  authors  would  like  to  thank  the  Transformational  Satellite  Communications  System  (TSAT) 
program  for  sponsoring  this  technical  note.  In  addition,  Lt  Col  Christopher  Beres,  Suellen  Eslin- 
ger,  Leslie  Holloway,  John  Foreman,  Myron  Hecht,  Renay  Campbell-Labriola,  Libby  Fenelsen, 
Ed  Perez,  and  Robert  Borich  provided  assistance  with  the  information  in  this  report. 

In  addition,  one  of  the  authors,  Julie  Cohen,  completed  some  of  this  effort  while  working  as  an 
Air  Force  civil  servant  under  the  Intergovernmental  Personnel  Act. 


vii  |  CMU/SEI-201 0-TN-01 4 


viii  |  CMU/SEI-2010-TN-014 


About  This  Report 


This  technical  note  is  a  result  of  work  that  was  done  for  the  Transformational  Satellite  Communi¬ 
cations  System  (TSAT)  program.  While  writing  the  Request  for  Proposal  (RFP)  for  the  TSAT 
Mission  Operations  Segment  (TMOS),  data  rights  for  proprietary  software  were  considered  and 
the  TMOS  team  wrote  specific  data  rights  language.  This  language  was  then  refined  for  the  Space 
Segment  source  selection.  The  result  of  that  work  forms  the  basis  for  this  report  in  the  hope  that  it 
will  provide  assistance  to  other  Department  of  Defense  (DoD)  programs  facing  similar  challenges. 
There  is  also  one  section  that  describes  the  approach  the  Global  Positioning  System  (GPS)  pro¬ 
gram  office  took  toward  data  rights.  Its  approach  was  different  from  the  TSAT  approach,  but 
should  be  considered  when  a  program  is  determining  how  to  approach  software  data  rights. 
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Abstract 


The  Department  of  Defense  (DoD)  is  increasingly  acquiring  complex  systems  that  use  commer¬ 
cial  software  to  meet  many  of  the  systems’  functional  requirements.  If  the  commercial  software  is 
a  truly  commercial  product  and  will  not  be  modified  (for  example,  a  commercial  antivirus  pro¬ 
gram),  then  for  most  systems,  data  rights  do  not  become  an  issue.  However,  when  the  commercial 
software  is  based  on  proprietary  software  that  is  not  available  as  a  standard  commercial  product  or 
will  be  modified  such  that  the  end  product  is  no  longer  commercially  available  or  is  different  from 
the  standard  commercial  product  (for  example,  adding  program  specific  capabilities  to  a  database 
program),  the  DoD  must  consider  what  data  rights  are  necessary. 

This  paper 

•  examines  how  data  rights  issues  were  addressed  in  the  Transformational  Satellite  Communi¬ 
cations  System  (TSAT)  program 

•  reviews  additional  concerns  posed  by  the  use  of  commercial  software  in  the  TSAT  pro¬ 
gram’s  Space  Segment,  including  safety  and  mission  assurance,  and  how  those  concerns 
were  addressed 

•  reviews,  in  less  detail,  data  rights  concerns  for  software  incorporated  in  the  Global  Position¬ 
ing  System  program,  and  how  those  concerns  were  addressed 
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1  Introduction 


This  technical  note  was  written  to  document  the  data  rights  language  used  in  the  TSAT  program. 
The  approach  was  different  from  what  had  been  used  previously  by  the  Space  and  Missile  Sys¬ 
tems  Center  (SMC)  due  to  the  desire  to  use  commercial  products.  The  TMOS  and  TSAT  expe¬ 
riences  are  meant  as  examples  only,  are  not  necessarily  comprehensive,  and  should  be  reviewed 
and  adapted  if  used  for  other  programs. 

Sections  2-6  of  this  report  all  have  the  same  format.  They  all  begin  with  an  explanation  of  what 
occurred  on  the  TMOS  and  Space  Segments.  These  explanations  are  meant  to  help  with  the  un¬ 
derstanding  of  the  general  recommendations  and  lessons  learned.  If  you  are  only  interested  in  the 
general  guidance  you  can  skip  directly  to  those  sections. 

Section  7  describes  the  approach  the  GPS  program  took  with  regards  to  data  rights. 

Section  8  includes  contract  language  from  both  TSAT  and  GPS. 

FAR  and  DFAR  documents  can  be  found  at  the  following  web  address:  http://farsite.hill.af.mil/ 


NOTE:  Throughout  the  report,  direct  quotations  from  FAR  and  DFAR  documents  will  be  format¬ 
ted  in  a  sans-serif  typeface: 

This  is  an  example  of  a  direct  quote  from  FAR. 
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2  Terminology 


This  section  will  define  the  basic  terminology  used  in  this  technical  note.  These  definitions  in¬ 
clude  both  terminology  for  software  classes  and  data  rights.  Where  applicable,  the  definitions  are 
taken  from  federal  acquisition  regulation  (FAR)  or  defense  federal  acquisition  (DFAR)  refer¬ 
ences.  Since  the  FAR  and  DFAR  are  subject  to  change,  be  sure  to  refer  to  a  current  copy  of  these 
regulations  before  using  the  definitions  in  any  contractual  documents. 

Definitions  specific  to  the  data  rights  issue  will  be  defined  in  Section  4. 

2.1  Software  Categories 

When  dealing  with  software  data  rights  the  authors  considered  different  categories  of  software. 
Terminology  related  to  these  different  categories  is  discussed  below  and  encompasses  new,  reuse 
and  COTS  software. 

2.1.1  Commercial  Off-The-Shelf  Component 

A  component  that  is  (a)  sold,  leased,  or  licensed  to  the  general  public,  (b)  offered  by  a  vendor  try¬ 
ing  to  profit  from  it,  (c)  supported  and  evolved  by  the  vendor,  who  retains  the  intellectual  property 
rights,  (d)  available  in  multiple,  identical  copies;  used  without  modification  of  the  internals  [Ob- 
erndorf  2000]. 

2.1.2  Commercial  Item 

The  FAR  (2.101)  definition  is  as  follows: 

“Commercial  item”  means  — 

(1)  Any  item,  other  than  real  property,  that  is  of  a  type  customarily  used  by  the  general 
public  or  by  non-governmental  entities  for  purposes  other  than  governmental  purposes, 
and  — 

(i)  Has  been  sold,  leased,  or  licensed  to  the  general  public;  or, 

(ii)  Has  been  offered  for  sale,  lease,  or  license  to  the  general  public; 

(2)  Any  item  that  evolved  from  an  item  described  in  paragraph  (1)  of  this  definition  through 
advances  in  technology  or  performance  and  that  is  not  yet  available  in  the  commercial 
marketplace,  but  will  be  available  in  the  commercial  marketplace  in  time  to  satisfy  the 
delivery  requirements  under  a  Government  solicitation; 

(3)  Any  item  that  would  satisfy  a  criterion  expressed  in  paragraphs  (1)  or  (2)  of  this  defini¬ 
tion,  but  for  — 

(i)  Modifications  of  a  type  customarily  available  in  the  commercial  marketplace;  or 

(ii)  Minor  modifications  of  a  type  not  customarily  available  in  the  commercial 
marketplace  made  to  meet  Federal  Government  requirements.  Minor 
modifications  means  modifications  that  do  not  significantly  alter  the 
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nongovernmental  function  or  essential  physical  characteristics  of  an  item  or 
component,  or  change  the  purpose  of  a  process.  Factors  to  be  considered  in 
determining  whether  a  modification  is  minor  include  the  value  and  size  of  the 
modification  and  the  comparative  value  and  size  of  the  final  product.  Dollar 
values  and  percentages  may  be  used  as  guideposts,  but  are  not  conclusive 
evidence  that  a  modification  is  minor; 

(4)  Any  combination  of  items  meeting  the  requirements  of  paragraphs  (1),  (2),  (3),  or  (5)  of 
this  definition  that  are  of  a  type  customarily  combined  and  sold  in  combination  to  the 
general  public; 

(5)  Installation  services,  maintenance  services,  repair  services,  training  services,  and  other 
services  if  — 

(i)  Such  services  are  procured  for  support  of  an  item  referred  to  in  paragraph  (1), 

(2),  (3),  or  (4)  of  this  definition,  regardless  of  whether  such  services  are  provided 
by  the  same  source  or  at  the  same  time  as  the  item;  and 

(ii)  The  source  of  such  services  provides  similar  services  contemporaneously  to  the 
general  public  under  terms  and  conditions  similar  to  those  offered  to  the  Federal 
Government; 

(6)  Services  of  a  type  offered  and  sold  competitively  in  substantial  quantities  in  the  com¬ 
mercial  marketplace  based  on  established  catalog  or  market  prices  for  specific  tasks 
performed  or  specific  outcomes  to  be  achieved  and  under  standard  commercial  terms 
and  conditions.  For  purposes  of  these  services  — 

(i)  “Catalog  price”  means  a  price  included  in  a  catalog,  price  list,  schedule,  or  other 
form  that  is  regularly  maintained  by  the  manufacturer  or  vendor,  is  either 
published  or  otherwise  available  for  inspection  by  customers,  and  states  prices  at 
which  sales  are  currently,  or  were  last,  made  to  a  significant  number  of  buyers 
constituting  the  general  public;  and 

(ii)  “Market  prices”  means  current  prices  that  are  established  in  the  course  of 
ordinary  trade  between  buyers  and  sellers  free  to  bargain  and  that  can  be 
substantiated  through  competition  or  from  sources  independent  of  the  offerors. 

(7)  Any  item,  combination  of  items,  or  service  referred  to  in  paragraphs  (1)  through  (6)  of 
this  definition,  notwithstanding  the  fact  that  the  item,  combination  of  items,  or  service  is 
transferred  between  or  among  separate  divisions,  subsidiaries,  or  affiliates  of  a  contrac¬ 
tor;  or 

(8)  A  nondevelopmental  item,  if  the  procuring  agency  determines  the  item  was  developed 
exclusively  at  private  expense  and  sold  in  substantial  quantities,  on  a  competitive  basis, 
to  multiple  State  and  local  governments. 

2.1 .3  Proprietary  Software  (Developed  at  Private  Expense) 

The  DFARS  definition  (252.227-7013)  is  as  follows: 

“Developed  exclusively  at  private  expense”  means  development  was  accomplished  entirely 

with  costs  charged  to  indirect  cost  pools,  costs  not  allocated  to  a  government  contract,  or  any 

combination  thereof. 
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(i)  Private  expense  determinations  should  be  made  at  the  lowest  practicable  level. 

(ii)  Under  fixed-price  contracts,  when  total  costs  are  greater  than  the  firm-fixed-price 
or  ceiling  price  of  the  contract,  the  additional  development  costs  necessary  to 
complete  development  shall  not  be  considered  when  determining  whether 
development  was  at  government,  private,  or  mixed  expense. 

2.1.4  Software  Developed  at  the  DoD’s  Expense 

The  DFARS  (252.227-7013)  definition  is 

“Developed  exclusively  with  government  funds”  means  development  was  not  accomplished 
exclusively  or  partially  at  private  expense. 

In  some  instances,  DoD  systems  are  developed  using  a  mixture  of  funding.  The  DFAR  definition 
is 

“Developed  with  mixed  funding”  means  development  was  accomplished  partially  with  costs 
charged  to  indirect  cost  pools  and/or  costs  not  allocated  to  a  government  contract,  and  par¬ 
tially  with  costs  charged  directly  to  a  government  contract. 

2.1.5  Restricted  Computer  Software 

The  FAR  (52.227-14)  definition  is 

[CJomputer  software  developed  at  private  expense  and  that  is  a  trade  secret,  is  commercial 
or  financial,  and  is  confidential  or  privileged;  or  is  published  copyrighted  computer  software, 
including  minor  modifications  of  such  computer  software. 

2.2  Categories  of  Data  Rights 

There  are  different  categories  for  computer  software  and  hardware  data  rights.  The  software  data 
rights  from  FAR  are  in  section  252.7014;  from  DFARS  they  are  found  in  DFARS  227.7203-5, 
Government  rights. 

The  standard  license  rights  in  computer  software  that  a  licensor  grants  to  the  Government 
are  unlimited  rights,  Government  purpose  rights,  or  restricted  rights.  The  standard  license  in 
computer  software  documentation  conveys  unlimited  rights.  Those  rights  are  defined  in  the 
clause  at  FAR  252.227-7014,  Rights  in  Noncommercial  Computer  Software  and  Noncom¬ 
mercial  Computer  Software  Documentation.  In  unusual  situations,  the  standard  rights  may 
not  satisfy  the  Government's  needs  or  the  Government  may  be  willing  to  accept  lesser  rights 
in  return  for  other  consideration.  In  those  cases,  a  special  license  may  be  negotiated.  How¬ 
ever,  the  licensor  is  not  obligated  to  provide  the  Government  greater  rights  and  the  contract¬ 
ing  officer  is  not  required  to  accept  lesser  rights  than  the  rights  provided  in  the  standard  grant 
of  license. 

The  situations  under  which  a  particular  grant  of  license  applies  are  enumerated  in  paragraphs 
(a)  through  (d)  of  DFAR  227.7203-5.  For  hardware  data  rights,  DFAR  states  in  SUBPART 
227.4— RIGHTS  IN  DATA  AND  COPYRIGHTS,  227.400  Scope  of  subpart: 
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DoD  activities  shall  use  the  guidance  in  Subparts  227.71  and  227 .72  instead  of  the  guidance 
in  FAR  Subpart  27.4.  Subparts  227.71  and  227.72  call  out  the  same  categories  for  hardware 
data  rights,  unlimited,  Government  purpose,  or  restricted  rights. 

2.2.1  Limited  Rights 

Note  that  the  definitions  in  FAR  clause  252.227-7013  do  not  pertain  to  computer  software.  They 
have  been  included  for  completeness.  The  FAR  definition  of  limited  rights  (252.227-7013)  is  as 
follows: 

(13)  “Limited  rights”  means  the  rights  to  use,  modify,  reproduce,  release,  perform,  display,  or 
disclose  technical  data,  in  whole  or  in  part,  within  the  Government.  The  Government 
may  not,  without  the  written  permission  of  the  party  asserting  limited  rights,  release  or 
disclose  the  technical  data  outside  the  Government,  use  the  technical  data  for  manufac¬ 
ture,  or  authorize  the  technical  data  to  be  used  by  another  party,  except  that  the  Gov¬ 
ernment  may  reproduce,  release  or  disclose  such  data  or  authorize  the  use  or  reproduc¬ 
tion  of  the  data  by  persons  outside  the  Government  if  reproduction,  release,  disclosure, 
or  use  is  — 

(i)  Necessary  for  emergency  repair  and  overhaul;  or 

(ii)  A  release  or  disclosure  of  technical  data  (other  than  detailed  manufacturing  or 
process  data)  to,  or  use  of  such  data  by,  a  foreign  government  that  is  in  the 
interest  of  the  Government  and  is  required  for  evaluational  or  informational 
purposes; 

(iii)  Subject  to  a  prohibition  on  the  further  reproduction,  release,  disclosure,  or  use  of 
the  technical  data;  and 

(iv)  The  contractor  or  subcontractor  asserting  the  restriction  is  notified  of  such 
reproduction,  release,  disclosure,  or  use. 

2.2.2  Unlimited  Rights 

The  FAR  definition  of  unlimited  rights  (27.401)  is  as  follows: 

“Unlimited  rights”  means  the  rights  of  the  Government  to  use,  disclose,  reproduce,  prepare 
derivative  works,  distribute  copies  to  the  public,  and  perform  publicly  and  display  publicly,  in 
any  manner  and  for  any  purpose,  and  to  have  or  permit  others  to  do  so. 

And  the  DFARS  clause  dealing  with  unlimited  rights  with  respect  to  software  (52.227-05)  states: 

(a)  Unlimited  rights.  The  Government  obtains  an  unlimited  rights  license  in  — 

(1 )  Computer  software  developed  exclusively  with  Government  funds; 

(2)  Computer  software  documentation  required  to  be  delivered  under  a  Government 
contract; 

(3)  Corrections  or  changes  to  computer  software  or  computer  software  documenta¬ 
tion  furnished  to  the  contractor  by  the  Government; 

(4)  Computer  software  or  computer  software  documentation  that  is  otherwise  public¬ 
ly  available  or  has  been  released  or  disclosed  by  the  contractor  or  subcontractor 
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without  restrictions  on  further  use,  release  or  disclosure  other  than  a  release  or 
disclosure  resulting  from  the  sale,  transfer,  or  other  assignment  of  interest  in  the 
software  to  another  party  or  the  sale  or  transfer  of  some  or  all  of  a  business  entity 
or  its  assets  to  another  party; 

(5)  Computer  software  or  computer  software  documentation  obtained  with  unlimited 
rights  under  another  Government  contract  or  as  a  result  of  negotiations;  or 

(6)  Computer  software  or  computer  software  documentation  furnished  to  the  Gov¬ 
ernment,  under  a  Government  contract  or  subcontract  with  — 

(i)  Restricted  rights  in  computer  software,  limited  rights  in  technical  data,  or 
government  purpose  license  rights  and  the  restrictive  conditions  have 
expired;  or 

(ii)  Government  purpose  rights  and  the  contractor's  exclusive  right  to  use 
such  software  or  documentation  for  commercial  purposes  has  expired. 

2.2.3  Government  Purpose  Rights 

The  DFARS  (227.7203-5)  defines  government  purpose  rights  as  follows: 

“Government  purpose  rights”  means  the  rights  to  — 

(i)  Use,  modify,  reproduce,  release,  perform,  display,  or  disclose  technical 
data  within  the  Government  without  restriction;  and 

(ii)  Release  or  disclose  technical  data  outside  the  Government  and 
authorize  persons  to  whom  release  or  disclosure  has  been  made  to  use, 
modify,  reproduce,  release,  perform,  display,  or  disclose  that  data  for 
United  States  government  purposes. 

And  government  purpose  is  defined  as  follows: 

“Government  purpose”  means  any  activity  in  which  the  United  States  Government  is  a  party, 
including  cooperative  agreements  with  international  or  multi-national  defense  organizations, 
or  sales  or  transfers  by  the  United  States  Government  to  foreign  governments  or  international 
organizations.  Government  purposes  include  competitive  procurement,  but  do  not  include  the 
rights  to  use,  modify,  reproduce,  release,  perform,  display,  or  disclose  technical  data  for 
commercial  purposes  or  authorize  others  to  do  so. 

2.2.4  Restricted  Rights 

The  DFARS  definition  (52.227-05)  of  restricted  rights  is: 

(c)  Restricted  rights. 

(1)  The  Government  obtains  restricted  rights  in  noncommercial  computer  software 
required  to  be  delivered  or  otherwise  provided  to  the  Government  under  a  con¬ 
tract  that  were  developed  exclusively  at  private  expense. 

(2)  Contractors  are  not  required  to  provide  the  Government  additional  rights  in  com¬ 
puter  software  delivered  or  otherwise  provided  to  the  Government  with  restricted 
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rights.  When  the  Government  has  a  need  for  additional  rights,  the  Government 
must  negotiate  with  the  contractor  to  determine  if  there  are  acceptable  terms  for 
transferring  such  rights.  List  or  describe  all  software  in  which  the  contractor  has 
granted  the  Government  additional  rights  in  a  license  agreement  made  part  of 
the  contract  (see  paragraph  (d)  of  this  subsection).  The  license  shall  enumerate 
the  specific  additional  rights  granted  to  the  Government. 

2.2.5  Specially  Negotiated  Rights 

The  FAR  definition  of  specially  negotiated  rights  in  under  FAR  227.7103-5,  Government  rights. 
Note  that  the  definitions  in  FAR  clause  252.227-7013  do  not  pertain  to  computer  software.  They 
have  been  included  for  completeness. 

The  standard  license  rights  that  a  licensor  grants  to  the  Government  are  unlimited  rights, 
government  purpose  rights,  or  limited  rights.  Those  rights  are  defined  in  the  clause  at 
252.227-7013,  Rights  in  Technical  Data — Noncommercial  Items.  In  unusual  situations,  the 
standard  rights  may  not  satisfy  the  Government's  needs  or  the  Government  may  be  willing  to 
accept  lesser  rights  in  data  in  return  for  other  consideration.  In  those  cases,  a  special  license 
may  be  negotiated.  However,  the  licensor  is  not  obligated  to  provide  the  Government  greater 
rights  and  the  contracting  officer  is  not  required  to  accept  lesser  rights  than  the  rights  pro¬ 
vided  in  the  standard  grant  of  license.  The  situations  under  which  a  particular  grant  of  license 
applies  are  enumerated  in  paragraphs  (a)  through  (d)  of  this  FAR  subsection.  Paragraph  d 
covers  specifically  negotiated  rights  as  shown  below: 

(d)  Specifically  negotiated  license  rights. 

(1 )  Negotiate  specific  licenses  when  the  parties  agree  to  modify  the  standard  license 
rights  granted  to  the  Government  or  when  the  Government  wants  to  obtain  rights 
in  data  in  which  it  does  not  have  rights.  When  negotiating  to  obtain,  relinquish,  or 
increase  the  Government's  rights  in  technical  data,  consider  the  acquisition  strat¬ 
egy  for  the  item,  component,  or  process,  including  logistics  support  and  other 
factors  which  may  have  relevance  for  a  particular  procurement.  The  Government 
may  accept  lesser  rights  when  it  has  unlimited  or  government  purpose  rights  in 
data  but  may  not  accept  less  than  limited  rights  in  such  data.  The  negotiated  li¬ 
cense  rights  must  stipulate  what  rights  the  Government  has  to  release  or  dis¬ 
close  the  data  to  other  persons  or  to  authorize  others  to  use  the  data.  Identify  all 
negotiated  rights  in  a  license  agreement  made  part  of  the  contract. 

(2)  When  the  Government  needs  additional  rights  in  data  acquired  with  government 
purpose  or  limited  rights,  the  contracting  officer  must  negotiate  with  the  contrac¬ 
tor  to  determine  whether  there  are  acceptable  terms  for  transferring  such  rights. 
Generally,  such  negotiations  should  be  conducted  only  when  there  is  a  need  to 
disclose  the  data  outside  the  Government  or  if  the  additional  rights  are  required 
for  competitive  reprocurement  and  the  anticipated  savings  expected  to  be  ob¬ 
tained  through  competition  are  estimated  to  exceed  the  acquisition  cost  of  the 
additional  rights.  Prior  to  negotiating  for  additional  rights  in  limited  rights  data, 
consider  alternatives  such  as  — 
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(i)  Using  performance  specifications  and  form,  fit,  and  function  data  to 
acquire  or  develop  functionally  equivalent  items,  components,  or 
processes; 

(ii)  Obtaining  a  contractor's  contractual  commitment  to  qualify  additional 
sources  and  maintain  adequate  competition  among  the  sources;  or 

(iii)  Reverse  engineering,  or  providing  items  from  Government  inventories  to 
contractors  who  request  the  items  to  facilitate  the  development  of 
equivalent  items  through  reverse  engineering. 


2.2.6  DoD  Policy 

DoD  policy  is  to  only  acquire  the  minimum  necessary  data  rights  when  using  commercial  prod¬ 
ucts,  so  each  program  needs  to  ensure  they  have  determined  what  is  actually  required.  The  DoD 

policy  regarding  hardware  is  in  FAR  part  227.7102-1;  the  software -related  policy  is  in  227.7202- 

1.  Both  are  provided  below. 

2.2.6.1  227.7102-1  Policy 

(a)  DoD  shall  acquire  only  the  technical  data  customarily  provided  to  the  public  with  a  “com¬ 
mercial  item”  or  process,  except  technical  data  that  — 

(1)  Are  form,  fit,  or  function  data; 

(2)  Are  required  for  repair  or  maintenance  of  commercial  items  or  processes,  or  for 
the  proper  installation,  operating,  or  handling  of  a  commercial  item,  either  as  a 
standalone  unit  or  as  a  part  of  a  military  system,  when  such  data  are  not  custo¬ 
marily  provided  to  commercial  users  or  the  data  provided  to  commercial  users  is 
not  sufficient  for  military  purposes;  or 

(3)  Describe  the  modifications  made  at  Government  expense  to  a  commercial  item 
or  process  in  order  to  meet  the  requirements  of  a  Government  solicitation. 

(b)  To  encourage  offerors  and  contractors  to  offer  or  use  commercial  products  to  satisfy  mili¬ 
tary  requirements,  offerors  and  contractors  shall  not  be  required,  except  for  the  technical 
data  described  in  paragraph  (a)  of  this  subsection,  to  — 

(1)  Furnish  technical  information  related  to  commercial  items  or  processes  that  is  not 
customarily  provided  to  the  public;  or 

(2)  Relinquish  to,  or  otherwise  provide,  the  Government  rights  to  use,  modify,  repro¬ 
duce,  release,  perform,  display,  or  disclose  technical  data  pertaining  to  commer¬ 
cial  items  or  processes  except  for  a  transfer  of  rights  mutually  agreed  upon. 

2. 2. 6.2  227.7202-1  Policy 

(a)  Commercial  computer  software  or  commercial  computer  software  documentation  shall  be 
acquired  under  the  licenses  customarily  provided  to  the  public  unless  such  licenses  are 
inconsistent  with  Federal  procurement  law  or  do  not  otherwise  satisfy  user  needs. 
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(b)  Commercial  computer  software  and  commercial  computer  software  documentation  shall 
be  obtained  competitively,  to  the  maximum  extent  practicable,  using  firm-fixed-price  con¬ 
tracts  or  firm-fixed-priced  orders  under  available  pricing  schedules. 

(c)  Offerors  and  contractors  shall  not  be  required  to  — 

(1)  Furnish  technical  information  related  to  commercial  computer  software  or  com¬ 
mercial  computer  software  documentation  that  is  not  customarily  provided  to  the 
public  except  for  information  documenting  the  specific  modifications  made  at 
Government  expense  to  such  software  or  documentation  to  meet  the  require¬ 
ments  of  a  Government  solicitation;  or 

(2)  Relinquish  to,  or  otherwise  provide,  the  Government  rights  to  use,  modify,  repro¬ 
duce,  release,  perform,  display,  or  disclose  commercial  computer  software  or 
commercial  computer  software  documentation  except  for  a  transfer  of  rights  mu¬ 
tually  agreed  upon. 
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3  Data  Rights  Risk  Analysis 


3.1  TMOS  Experience 

The  TMOS  team  started  by  looking  at  the  risks  that  would  be  introduced  if  data  rights  could  not 
be  obtained  for  proprietary  software  that  is  used  to  meet  critical  system  requirements.  There  were 
four  main  risk  areas: 

(1)  Decreased  development/integration  visibility 

There  will  most  likely  be  limited  or  no  access  to  detailed  design  information  and  source 
code;  the  government  will  have  overall  decreased  development  visibility,  and  less  insight  in¬ 
to  test  and  integration  status. 

(2)  Long-term  sustainment  issues 

The  detailed  design  information  and  source  code  will  not  be  delivered;  the  government  will 
need  to  rely  on  the  developing  company  for  support  throughout  the  entire  TSAT  lifetime. 

(3)  Compatibility/interoperability  issues 

The  detailed  design  information  and  source  code  will  not  be  delivered  and  the  ability  to  inte¬ 
grate  TSAT  with  future  systems  (backward  compatibility/interoperability)  will  likely  be  af¬ 
fected. 

(4)  Increased  deployment  costs 

The  government  may  have  to  license  each  instance  of  the  software  separately;  licensing  fees 
can  be  excessive  if  the  government  needs  additional  sites. 

TMOS  reformulated  these  risks  into  the  following  if-then  statements: 

Decreased  development/integration  visibility 

If  the  government  and  other  TSAT  contractors  have  less  visibility  into  development, 
test,  and  intra-  and  inter-segment  integration  due  to  restricted  access  to  detailed  de¬ 
sign  information  and  source  code,  then  the  development  may  not  be  defect-free,  lead¬ 
ing  to  late  error  discovery  during  test,  or  interoperability  failure  during  integration. 

Long-term  sustainment  issues 

If  the  government  needs  to  rely  solely  on  the  developer  for  support  throughout  TSAT 
operational  life  due  to  detailed  design  information  and  source  code  not  having  been 
delivered,  then  the  developer  may  charge  an  exorbitant  price  for  sustainment  or  unila¬ 
terally  choose  to  discontinue  support. 

Compatibility /interoperability  issues 

If  the  government  needs  to  rely  solely  on  the  developer  for  interoperability  with  fu¬ 
ture  systems  due  to  detailed  design  information  and  source  code  not  having  been  de¬ 
livered,  then  the  developer  may  demand  uncompetitive,  undesirable  terms  of  their  in¬ 
volvement  in  the  future  systems. 
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Increased  deployment  costs 

If  the  government  has  to  license  each  instance  of  the  software  separately,  then  the 
vendor  may  charge  the  government  excessive  fees  to  add  sites  at  a  later  date. 

3.2  Space  Segment  Experience 

The  Space  Segment  used  the  same  risks  as  TMOS. 

3.3  General  Guidance 

These  risks  would  apply  to  most  large  DoD  acquisitions.  Some  acquisitions  may  identify  addi¬ 
tional  risks  associated  with  data  rights.  These  might  take  the  form  of  much  more  specific  risks  for 
known  critical  interfaces  or  additional  general  risks,  such  as  risks  arising  from  an  enterprise-based 
approach,  where  data  rights  issues  in  one  element  of  an  enterprise  system  could  affect  the  entire 
enterprise. 

Note:  This  report,  by  design,  only  addresses  business  and  contracting  risks  related  to  software  that 
drive  data  rights  considerations.  Other  software  risks,  such  as  financial,  user  base  stability,  and 
information  assurance,  if  relevant,  can  be  addressed  by  other  means.  In  addition,  even  the  risks 
explained  in  this  report  would  need  to  be  more  precisely  defined  in  terms  of  possible  outcomes 
and  consequences  if  to  be  used  for  risk  quantification  during  program  execution. 

3.4  Lessons  Learned 

These  risk  statements  succeeded  in  explaining  the  risks  involved  in  the  data  rights  issues  to  upper 
level  management.  They  were  at  about  the  right  level  of  detail  to  get  the  message  across.  For  top- 
level  summary  presentations,  these  were  summarized  as  risk  in  four  areas:  development,  interope¬ 
rability,  maintenance,  and  deployment. 
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4  Data  Rights  Definition  Development 


Note:  For  the  final  recommended  wording,  see  Section  4.2. 

4.1  TMOS  Experience 

After  the  risk  statements  were  developed,  the  next  step  was  to  determine  which  types  of  data 
needed  more  than  restricted  rights.  It  was  clear  that  it  would  be  impossible  get  unlimited  rights  or 
even  the  standard  DFAR  government  purpose  rights  while  still  encouraging  the  use  of  commer¬ 
cially  developed,  non-COTS  software  products.  The  use  of  commercially  developed  products  had 
been  encouraged  to  reduce  cost  and  increase  technical  maturity,  but  the  data  rights  issues  had  not 
yet  been  addressed.  The  goal  was  to  find  a  way  to  pay  a  fair  value  for  the  needed  rights  that  would 
allow  the  DoD  to  have  the  development  oversight,  maintenance  options,  and  information  needed 
to  ensure  compatibility  while  protecting  the  commercial  “crown  jewels”  of  the  offerors. 

The  approach  the  TMOS  team  took  was  to  define  specific  data  sets  and  specific  sets  of  users.  The 
offerors  were  then  asked  to  include  in  their  proposals  the  costs  to  provide  specific  data  rights  to 
these  users.  For  the  TMOS  case,  there  were  seven  different  data  sets  and  six  sets  of  users. 

4.1.1  TMOS  Data  Sets 

4.1 .1 .1  Source  Code  Viewing  Only 

This  data  set  provides  the  ability  for  personnel  to  review  all  source  code  (see  Section  4.1.1 .4, 
Source  Code  Delivery,  for  what  should  be  made  available)  associated  with  a  product.  The  devel¬ 
oper  will  likely  oversee  this  activity.  This  data  set  is  recommended  for  all  critical  software  and  for 
all  modified  software. 

Note:  The  identification  of  "critical  software"  is  necessarily  subjective  and  case  specific.  The  pro¬ 
gram  will  need  to  define  what  is  meant  by  critical  software. 

4.1 .1.2  Architecture-Level  Design  Information 

Architecture-level  design  information  will  be  used  to  convey  top  level  information  regarding  a 
specific  software  product  and  includes  (with  updates  as  needed) 

•  software  architecture  information 

views  showing  all  executable  processes,  where  they  execute  at  runtime,  and  how  they  in¬ 
teract 

hierarchical  view  of  all  software  modules  (“calling  tree”) 

•  overall  design  concept 

•  decomposition  and  functional  descriptions  of  the  major  components,  to  include  the  language 
used 

•  details  of  all  external  interfaces  (timing  information,  data  specs,  boundary  conditions,  per¬ 
formance  constraints,  protocols,  messages,  and  so  forth),  including  the  data  dictionary  for  all 
data  available  at  the  external  interfaces 
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•  overview  of  error/exception  handling  strategy 

•  top-level  information  on  database/data  file  structure(s)/schema 

•  information  on  any  hardware/other  software  needed  to  run  the  application 

This  data  set  is  recommended  for  any  projects  where  the  software  in  question  has  to  interface  to 
software  products  being  developed  by  a  different  contractor  or  under  a  different  contract.  It  is  also 
recommended  if  the  software  interfaces  with  other  internal  software  products  if  the  development 
contractor  will  not  maintain  the  system  over  its  lifetime. 

4.1 .1.3  Additional  Design  Information 

Additional  design  information  will  be  used  to  allow  more  detailed  inspection  of  the  software 
product  and  to  allow  greater  understanding  of  the  structure  and  functionality  for  maintenance  and 
interoperability  needs.  This  information  includes  (with  updates  as  needed) 

•  requirements  the  software  was  written  to  meet 

•  SW  architecture  views  below  the  module  level 

•  description  of  the  lowest  level  software  units  and  a  description  of  their  functionality 

•  internal  interface  information  (timing  information,  protocols,  data  specs,  etc.) 

•  database/data  file  internal  structure  and  description 

•  as  applicable,  built-in  security  features  and/or  built-in  safety  features 

•  user  interface  data — screen  architecture,  sequencing,  data  fields,  and  the  like 

•  performance  data  under  various  loading  conditions — speed,  memory,  and  CPU  utilization, 
reliability  data 

•  design  information  on  any  firmware  used  in  the  system 

This  data  set  is  recommended  for  any  projects  where  the  software  in  question  has  to  interface  to 
software  products  being  developed  by  a  different  contractor  or  under  a  different  contract.  This 
data  set  is  also  recommended  if  the  system  is  being  developed  using  a  block  approach  or  is  ex¬ 
pected  to  have  upgrades  done  over  the  life  of  the  system.  It  is  also  recommended  if  the  software 
interfaces  with  other  internal  software  products  if  the  development  contractor  will  not  maintain 
the  system  over  its  lifetime. 

4.1 .1 .4  Source  Code  Delivery 

Source  code  delivery  is  mainly  needed  for  maintenance  competition  purposes  and  includes  (with 
updates  as  needed) 

•  source  code,  libraries,  databases,  internal  data  files,  and  build  information 

•  detailed  information  on  COTS  products  needed  to  use  the  source  code  (preprocessors,  inter¬ 
preters,  etc.) 

•  all  software  development  folders 

•  other  information  needed  to  understand  and  execute  the  source  code 

•  configuration  information,  scripts,  and  the  like 

•  compilation  and  build  procedures 

•  algorithms,  parameters,  and  equations  used  to  produce  the  delivered  code 
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This  data  set  is  recommended  for  projects  where  the  development  contractor  is  not  expected  to  be 
the  maintainer  over  the  life  of  the  system. 

4.1 .1.5  Development  Environment  Information 

Development  environment  information  is  used  mainly  for  maintenance  competition  and  includes 
(with  updates  as  needed) 

•  detailed  description  of  all  COTS  hardware  and  software  used  to  develop  the  code 

•  delivery  of  all  proprietary  development  tools  and  databases 

•  information  on  how  to  configure,  run,  and  maintain  the  development  environment 

This  data  set  is  recommended  for  projects  where  the  development  contractor  is  not  expected  to  be 
the  maintainer  over  the  life  of  the  system. 

4.1 .1.6  Test  Information 

Test  information  includes  (with  updates  as  needed) 

•  all  scripts,  stubs,  parameters,  algorithms,  and  similar  information  used  for  testing  at  all  levels 
(that  is,  from  module  testing  through  full  integration  and  requirements  verification  for  testing 
the  baseline  code  and  any  changes  made  for  this  program) 

•  all  proprietary  software  and  hardware  required  for  testing 

•  test  plans  and  procedures,  to  include  regression  testing 

•  expected  test  results 

•  detailed  information  on  COTS  hardware  and  additional  software  required  for  testing  (auto¬ 
mated  test  tools,  etc.) 

This  data  set  is  recommended  for  projects  where  the  development  contractor  is  not  expected  to  be 
the  maintainer  over  the  life  of  the  system. 

4.1 .1.7  Unlimited  Licensing 

Unlimited  licensing  is  used  to  ensure  that  increased  licenses  costs  do  not  cause  funding  issues 
later  in  the  program.  Unlimited  licensing  includes  the  right  to  run  the  code  in  as  many  locations 
and  installations  as  needed. 

This  data  set  is  recommended  if  there  is  a  chance  that  the  system  may  expand  to  require  more 
software  licenses  after  the  initial  development  is  completed. 
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4.1.2  TMOS  User  Groups 

4.1 .2.1  TMOS  Program  Office 


The  TMOS  program  office  consists  of  all  government  (military  and  civilian)  personnel  assigned 
to  the  TMOS  program  office;  all  federally  funded  research  and  development  centers  (FFRDC) 
assigned  to  the  TMOS  program  office,  either  full-  or  part-time;  any  FFRDC  experts,  as  needed; 
and  all  systems  engineering  and  technical  assistance  (SETA)  contractors  assigned  full-time  to  the 
TMOS  program  office.  All  personnel  will  sign  non-disclosure  agreements  (NDAs). 

4.1 .2.2  TMOS  Contractor  Team 

The  TMOS  contractor  team  includes  all  contractors,  subcontractors  and  personnel  from  other  cor¬ 
porate  divisions  who  are  working  on  the  TMOS  contract.  Data  can  be  made  available  on  an  as- 
needed  basis. 

This  “user”  set  was  included  to  ensure  that  the  offeror’s  teammates  would  have  adequate  access  to 
proprietary  software  owned  by  another  teammate. 

4.1 .2.3  TSAT  Contractors 

TSAT  contractors  include  the  system  engineering  and  integration  (SE&I),  Space  Segment,  ter¬ 
minal  segment  and  global  information  grid  (GIG)  contractors.  All  personnel  will  sign  an  NDA. 
Information  will  be  released  to  these  users  on  an  as  needed  basis  as  determined  by  the  TMOS 
program  office. 

4.1 .2.4  Other  DoD  Contractors 

Other  DoD  contractors  include 

(1)  DoD  contractors  from  other  programs  that  may  have  to  interface  to  TSAT  (Future  Combat 
Systems,  Joint  Tactical  Radio  System,  etc.) 

(2)  DoD  contractors  that  are  bidding  on  or  executing  programs  that  need  to  be  backward  com¬ 
patible  with  or  interface  to  TSAT 

In  both  cases,  the  information  released  will  be  on  an  as-needed  basis  as  determined  by  the  gov¬ 
ernment.  All  personnel  will  sign  NDAs.  Personnel  in  the  government  program  office  related  to 
these  programs  will  have  access  to  the  same  data  as  their  contractors  have. 

4.1 .2.5  Air  Force  Depot 

Air  Force  depot  personnel  include  all  government  and  contractor  personnel  working  for  the  Air 
Force  depot  where  the  software  will  be  maintained  (currently  Hill  Air  Force  Base).  All  personnel 
will  sign  NDAs. 

4.1 .2.6  DoD  Contractors  for  Maintenance  Competition 

DoD  contractors  for  maintenance  include  any  DoD  contractors  that  are  working  on  or  bidding  on 
maintenance  contracts  for  TMOS  software,  solely  for  the  purpose  of  providing  maintenance.  All 
personnel  will  sign  NDAs. 
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For  TMOS,  the  offerors  were  told  that  competition  for  the  maintenance  for  TMOS  proprietary 
software  would  only  be  used  under  specific,  negotiated  conditions  of  maintenance  non¬ 
performance  by  the  developing  contractor  (for  example,  failure  to  meet  response  time  or  correct 
defects). 

4.2  Space  Segment  Experience: 

The  Space  Segment  used  very  similar  data  sets  and  user  groups,  with  the  names  modified  to  re¬ 
flect  Space  versus  TMOS.  The  data  set  and  user  group  definitions  were  updated  with  improve¬ 
ments  from  TMOS  lessons  learned  and  on  slightly  different  concerns  for  the  Space  Segment.  The 
updated  definitions  are  provided  below. 

4.2. 1.1  Source  Code  Viewing  Only 

Provides  the  ability  for  any  personnel  (within  the  groups  defined  below)  to  review  all  source  code 
(see  Section  4.2. 1.4,  Source  Code  Delivery,  for  what  should  be  made  available)  associated  with  a 
product  at  a  government-selected  facility.  The  developer  may  be  present  during  this  activity. 

4.2. 1.2  Architecture-Level  Design  Information 

Architecture-level  design  information  will  be  used  to  convey  top-level  information  regarding  a 
specific  software  product;  it  includes  (with  all  updates)  the  following: 

•  software  architecture  information 

views  showing  all  executable  processes,  where  they  execute  at  runtime,  and  how 
they  interact 

hierarchical  view  of  all  software  modules  (“calling  tree”) 

•  overall  design  concept 

•  decomposition  and  functional  descriptions  of  the  major  components,  to  include  the  language 
used 

•  details  of  all  external  interfaces  (timing  information,  data  specs,  boundary  conditions,  per¬ 
formance  constraints,  protocols,  messages,  and  the  like)  including  the  data  dictionary  for  all 
data  available  at  the  external  interfaces 

•  overview  of  error  and  exception  handling  strategy 

•  top-level  information  on  database  and  data  file  structure(s)  and  schema 

•  information  on  any  hardware  and  other  software  needed  to  run  the  application 

4.2. 1.3  Additional  Design  Information 

Additional  design  information  will  be  used  to  allow  more-detailed  inspection  of  the  software 
product  and  to  allow  greater  understanding  of  the  stmcture  and  functionality  for  maintenance  and 
interoperability  needs.  This  information  includes  (with  all  updates)  the  following: 

•  requirements  for  which  the  software  was  written  to  meet 

•  software  architecture  views  below  the  module  level 

•  description  of  the  lowest-level  software  units  and  a  description  of  their  functionality 

•  internal  interface  information  (timing  information,  protocols,  data  specs,  etc.) 
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•  database  and  data  file  internal  structure  and  description 

•  as  applicable,  built-in  security  features  and/or  built-in  safety  features 

•  user  interface  data — screen  architecture,  sequencing,  data  fields,  etc. 

•  performance  data  under  various  loading  conditions — speed,  memory,  and  CPU  utiliza¬ 
tion,  reliability  data 

4.2.1 .4  Source  Code  Delivery 

Source  code  delivery  includes  (with  all  updates)  the  following: 

•  source  code,  libraries,  databases,  internal  data  files,  and  build  information 

•  detailed  information  on  COTS  products  needed  to  use  the  source  code  (preprocessors,  inter¬ 
preters,  etc.) 

•  all  software  development  folders 

•  other  information  needed  to  understand  and  execute  the  source  code 

•  configuration  information,  scripts,  and  the  like 

•  compilation  and  build  procedures 

•  algorithms,  parameters,  and  equations  used  to  produce  the  delivered  code 

4.2. 1.5  Unlimited  Licensing 

Unlimited  licensing  includes  the  following: 

•  the  right  to  ran  the  code  in  as  many  locations  and  installations  as  needed  in  the  course  of 
executing  this  contract,  including  training,  testing,  additional  satellites  and/or  ground  site  op¬ 
tions;  if  unlimited  licensing  is  not  available,  state  the  terms  under  which  you  (the  contractor) 
are  willing  to  provide  a  long-term  (20  years  following  end  of  current  contract  period)  stable 
price  for  purchasing  up  to  twice  the  number  of  licenses  as  proposed  for  the  current  contract 

4.2.1 .6  Development  Environment  Information 

Development  environment  information  includes  (with  all  updates)  the  following: 

•  detailed  description  of  all  COTS  hardware  and  software  used  to  develop  the  code 

•  delivery  of  all  proprietary  development  tools  and  databases 

•  information  on  how  to  configure,  run,  and  maintain  the  development  environment 

4.2. 1.7  Test  Information 

Test  information  includes  (with  all  updates)  the  following: 

•  all  scripts,  stubs,  parameters,  algorithms,  and  similar  information  used  for  testing  at  all  levels 
(that  is,  from  module  testing  through  full  integration  and  requirements  verification  for  testing 
the  baseline  code,  and  any  changes  made  for  this  program) 

•  all  proprietary  software  and  hardware  required  for  testing 

•  test  plans  and  procedures,  to  include  regression  testing 

•  expected  test  results 
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•  detailed  information  on  COTS  hardware  and  additional  software  required  for  testing  (auto¬ 
mated  test  tools,  etc.) 

4.2.2  TSAT  Space  Segment  User  Groups 

4.2.2.1  TSAT  Space  Segment  Program  Office 

The  TSAT  Space  program  office  (SPO)  consists  of  all  government  (military  and  civilian)  person¬ 
nel  assigned  to  the  TSAT  Space  SPO;  all  FFRDCs  assigned  to  the  Space  SPO  either  full-  or  part 
time;  any  FFRDC  experts,  as  needed;  any  SETA  contractors  assigned  to  the  program  office  full- 
or  part-time.  All  non-government  personnel  shall  sign  NDAs  (government  personnel  are  covered 
by  the  Trade  Secrets  Act). 

4.2.2.2  TSAT  Space  Segment  Contractor  Team 

The  TSAT  Space  contractor  team  is  made  up  of  all  contractors,  subcontractors,  and  personnel 
from  other  corporate  divisions  who  are  working  on  the  TSAT  space  contract.  Data  can  be  made 
available  on  an  as-needed  basis. 

4.2.2.3  TSAT  Contractors 

TSAT  contractors  include  SE&I,  TMOS,  and  terminal  program  office  contractors.  All  non¬ 
government  personnel  will  sign  an  NDA.  This  shall  be  on  an  as-needed  basis  as  determined  by  the 
TSAT  Space  SPO.  Personnel  in  the  government  program  office  related  to  these  programs  will 
have  access  to  the  same  data  as  their  contractors  have.  For  the  purposes  of  this  definition,  the  gov¬ 
ernment  program  office  is  defined  in  the  same  manner  as  the  TSAT  space  SPO. 

4.2.2.4  Other  DoD  Contractors 

Other  DoD  contractors  include 

(1)  DoD  contractors  from  other  programs  that  may  have  to  interface  to  TSAT  (Future  Combat 
Systems,  Joint  Tactical  Radio  System,  Defense  Information  Systems  Agency,  and  the  like) 

(2)  DoD  contractors  that  are  bidding  on  or  executing  programs  that  need  to  be  backward  com¬ 
patible  with  or  interface  to  TSAT 

In  both  cases,  information  will  be  released  as  needed,  as  determined  by  the  government.  All  non¬ 
government  personnel  shall  sign  NDAs.  Personnel  in  the  government  program  office  related  to 
these  programs  will  have  access  to  the  same  data  as  their  contractors  have.  For  the  purposes  of 
this  definition,  the  government  program  office  is  defined  in  the  same  manner  as  the  TSAT  Space 
SPO. 

4.2.2.5  Air  Force  Depot 

The  Air  Force  depot  includes  all  government  and  contractor  personnel  working  for  the  Air  Force 
depot  where  the  software  will  be  maintained  (currently  Hill  Air  Force  Base).  All  non-government 
personnel  shall  sign  NDAs. 
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4.2.2.6  DoD  Maintenance  Contractors 


DoD  maintenance  contractors  include  any  DoD  contractors  working  on  or  bidding  on  mainten¬ 
ance  contracts  for  TSAT  Space  Segment  software,  solely  for  the  purpose  of  providing  mainten¬ 
ance.  All  non-government  personnel  shall  sign  NDAs. 

Note:  Competition  for  the  maintenance  for  TSAT  Space  Segment  software  would  be  used  only 
under  specific,  negotiated  conditions  of  non-performance  for  maintenance  by  the  developing  con¬ 
tractor  (for  example,  response  time,  defects,  etc.). 


4.3  Sample  Data  Set  Format 

The  following  format  was  developed  to  help  explain  these  data  sets.  This  format  is  used  in  Section 
5.  The  data  sets  are  shown  down  the  left  hand  side,  different  options  are  shown  across  the  top  and 
these  are  grouped  by  users  as  shown  on  the  right. 


Table  1:  Sample  Data  Set  Format 


Opt  1 

Opt  2 

Opt  3 

Architectural  Level  Design 

X 

X 

X 

Additional  Design  Info 

X 

X 

Source  Code 

X 

X 

Development  Environment 

X 

Test  Info 

X 

Architectural  Level  Design 

X 

X 

X 

Additional  Design  Info 

X 

X 

Source  Code 

X 

Development  Environment 

Test  Info 

Architectural  Level  Design 

X 

X 

Additional  Design  Info 

X 

Source  Code 

X 

Development  Environment 

Test  Info 

V) 

o 


o 

D. 


4.4  General  Guidance 
4.4.1  Data  Sets 

There  may  be  other  specific  data  that  a  program  needs,  for  example,  field-programmable  gate  ar¬ 
ray  or  firmware  data.  In  addition,  there  may  be  specific  test  sets  that  might  need  to  be  specifically 
included  in  a  data  set.  These  may  be  collapsed  into  smaller  groupings,  but  ensure  consideration  is 
given  to  what  data  is  needed  to  reduce  the  risks  in  all  the  areas  identified  in  Section  2. 
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4.4.2  User  Groups 

Other  programs  will  have  different  data  sets,  but  the  TMOS  and  Space  Segment  data  sets  can  be 
generalized  into  a  fairly  standard  set.  This  standard  set  would  always  include  the  government  pro¬ 
gram  office  in  charge  of  the  acquisition.  It  should  also  include  the  contractor  team  developing  the 
system  unless  all  the  software  is  being  developed  by  the  prime  contractor.  Even  if  it  appears  this 
may  be  the  case  when  the  RFP  is  being  prepared,  it  is  worthwhile  to  include  a  clause  related  to  a 
contractor  team  in  the  data  rights  language  in  case  subcontractors  do  develop  software  during  the 
life  of  the  program.  If  the  system  being  developed  has  to  interface  to  specific  systems,  then  the 
contractors  maintaining  or  developing  those  systems  should  also  be  included.  The  maintenance 
needs  for  the  system  must  also  be  considered.  Even  if  the  acquisition  strategy  calls  for  contractor 
logistics  support,  it  is  worthwhile  to  include  the  government  depot  at  a  minimum. 

4.5  Lessons  Learned 

Ensure  all  the  risks  identified  have  been  considered  and  assess  future  needs  as  well  as  current 
needs.  Request  personnel  outside  the  program  review  the  data  sets  and  the  user  sets.  The  authors 
also  encourage  a  legal  review  of  the  terms.  If  possible,  the  conditions  for  release  of  data  rights 
during  maintenance  should  be  discussed  with  all  interested  offerors  prior  to  final  RFP  release  ,  for 
example,  during  industry  days  so  that  better  definitions  of  release  conditions  can  be  included  in 
the  RFP. 
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5  TMOS  Data  Rights  Options 


5.1  TMOS  Experience 

After  determining  the  risks  involved  with  data  rights  and  defining  the  data  sets  and  user  groups, 
the  TMOS  team  developed  tables  to  help  visualize  the  available  options.  One  table  was  developed 
for  each  risk  area — development,  sustainment,  interoperability,  and  deployment.  The  tables  show 
the  various  options  that  might  be  available. 

5.1.1  Development  Data  Options 

The  development  data  options  involved  data  rights  needed  by  the  TMOS  program  office,  the 
TMOS  contractor  team  and  the  other  TSAT  contractors.  It  involved  the  data  sets  for  architectural 
level  information,  additional  design  information,  source  code  delivery,  the  development  environ¬ 
ment,  and  test  information.  The  development  data  options  assumed  that  the  TMOS  program  office 
and  the  TMOS  contractor  team  would  have  view-only  rights  to  the  source  code.  Table  1  shows  the 
options  considered  for  the  deployment  area.  For  example,  in  Option  5  the  TMOS  program  office 
would  have  rights  to  the  architectural-level  design  information,  the  additional  design  information, 
the  development  environment  information,  and  the  test  information.  The  TMOS  contractor  team 
would  have  access  to  the  architectural  and  other  design  information,  and  the  other  TSAT  contrac¬ 
tors  would  also  have  access  to  the  architectural  and  other  design  information. 
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Table  2:  TMOS  Development  Data  Options 


5.1.2  Sustainment  Data  Options 


The  sustainment  data  options  involve  data  rights  needed  by  the  depot  and  by  DoD  contractors 
bidding  to  maintain  the  system.  Table  2  shows  the  options  considered  for  the  sustainment  area. 
For  example,  in  Option  2  both  the  depot  and  DoD  maintenance  contractors  would  have  access  to 
all  the  data  sets. 


Table  3:  Sustainment  Data  Options 


Opt  1 

Opt  2 

Architectural  Level  Design 

Additional  Design  Info 

Source  Code 

Development  Environment 

Test  Info 

Architectural  Level  Design 

Additional  Design  Info 

Source  Code 

Development  Environment 

Test  Info 

5.1 .3  Interoperability  Data  Options 


o 

o 

Q 


O 

Q. 

0 

Q 


CO 


CD 
O 

c 
0 
c  o 
0  0 


c 

o 

o 


The  interoperability  data  options  involve  data  rights  needed  by  the  TMOS  program  office  and 
other  DoD  contractors  working  on  other  programs  that  need  to  interface  with  TSAT,  either  now  or 
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in  the  future.  Table  3  shows  the  options  for  these  data  sets.  As  can  be  seen  from  Table  3,  other 
DoD  contractors  would  never  have  access  to  proprietary  data  on  the  development  environment  or 
test  information. 

Table  4:  Interoperability  Data  Options 


Opt  1 

Opt  2 

Opt  3 

Architectural  Level  Design 

Additional  Design  Info 

Source  Code 

Development  Environment 

Test  Info 

js  o  c 
~  o  o 
O  Q  O 


5.1.4  Deployment  Data  Options 

The  deployment  data  options  involve  licensing  rights.  A  similar  result  could  be  achieved  using  an 
enterprise  licensing  approach,  but  the  TMOS  team  decided  to  consider  unlimited  licensing  op¬ 
tions.  There  were  only  two  options  for  unlimited  licensing:  either  provide  licenses  for  the  TMOS 
program  office,  for  operational  locations,  and  for  maintenance  use,  or  to  not  provide  unlimited 
licensing  at  all. 

5.2  Space  Segment  Experience 

The  TSAT  Space  Segment  started  with  the  TMOS  guidance,  but  made  some  changes  to  (1)  ensure 
the  appropriate  data  rights  covered  software  on  the  satellite,  (2)  correct  some  omissions  on  the 
TMOS  acquisition,  and  (3)  streamline  the  acquisition  processes.  Specifically,  Space  added  a  spe¬ 
cific  contract  clause  to  ensure  all  satellite-borne  software  would  have  source  code  viewing  rights 
for  mission  assurance  purposes,  including  unmodified  COTS  products.  They  also  were  direct  in 
stating  the  rights  desired,  but  allowed  for  different  proposals  with  acceptable  risk  mitigation. 
Tables  1-4  also  apply  to  the  Space  Segment  experience. 

The  Space  Segment  also  added  an  attachment  that  asked  some  very  specific  questions  regarding 
the  COTS/GOTS/reuse  software  to  help  determine  where  data  rights  might  be  needed.  This  at¬ 
tachment  had  several  tables,  as  explained  below. 

(1)  The  first  table  asked  for  a  listing  of  all  the  COTS  software  that  would  be  used.  The  offeror 
was  asked  to  supply  the  following  information: 

a.  the  name  of  the  COTS  component 

b.  a  short  description  (to  include  the  approximate  number  of  units  sold  if  under  100) 

c.  the  software  item  (SI)  or  items  where  the  product  would  be  used 

d.  if  modifications  would  be  made  (Yes/No)  Note:  “modification”  was  defined  as: 
“Modifications”  pertains  to  those  that  are  made  specifically  for  the  TSAT  program. 
Include  those  modifications  of  a  type  customarily  available  in  the  commercial  mar¬ 
ketplace;  or  minor  modifications  made  to  meet  Federal  Government  requirements 
that  do  not  significantly  alter  the  non-governmental  function  or  essential  physical 
characteristics  of  an  item  or  component,  or  change  the  purpose  of  a  process. 

e.  the  approximate  percentage  of  requirements  satisfied  by  the  COTS  product  for  each  SI 
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(2)  For  all  COTS  products  with  a  “Yes”  for  modifications,  the  next  table  asked  for  the  following 
information: 

a.  name  of  the  COTS  component 

b.  who  will  modify  product  (original  vendor;  TSAT  Space  contractor;  other  vendor) 

c.  the  approximate  percentage  of  the  code  that  will  be  changed 

d.  approximate  source  lines  of  code  (SLOC)  that  will  be  added 

e.  approximate  SLOC  count  for  the  COTS  product 

In  addition,  the  offerors  were  asked  to 

define  the  government  rights  they  would  assert  for  the  changed  portion  of  the  COTS 
component  and  to  provide  the  basis  for  their  assertion 

define  the  government  rights  they  would  assert  on  the  additional  information  regarding 
the  interfaces  between  the  changed  portion  of  the  code  and  the  pre-existing  COTS  com¬ 
ponent  and  provide  the  basis  for  their  assertion 

explain  in  detail  the  plan  for  providing  continuing  maintenance  for  the  modified  com¬ 
mercial  component  containing  the  changed  code 

explain  the  licensing  options  for  the  modified  commercial  component  containing  the 
changed  code 

(3)  The  next  table  asked  for  information  on  all  non-commercial  reused  software,  firmware,  and 
database  components  to  be  used  on  the  program  to  which  the  government  did  not  have  unli¬ 
mited  or  government  purpose  rights.  This  table  asked  for  the  following  information: 

a.  the  name  of  the  reuse  component 

b.  a  brief  description  of  the  reuse  component 

c.  the  SI(s)  where  used 

d.  the  data  rights  that  would  be  provided  to  the  government 

e.  the  approximate  percentage  of  requirements  satisfied  for  that  SI 

f.  the  SLOC  count  for  the  reused  code 

g.  the  percentage  of  reused  code  in  that  SI 

(4)  The  next  table  asked  for  information  on  all  the  COTS  and  reuse  products  with  other  than 
unlimited  or  government  purpose  rights.  This  table,  which  formed  the  basis  for  sustainment 
data  rights,  asked  for  the  following  information: 

a.  the  COTS  or  reuse  component  name 

b.  a  brief  description 

c.  the  basis  for  assertion  of  less  than  government  purpose  rights 

d.  the  option  price  to  provide  special  government  rights  for  sustainment 

(5)  The  next  table  asked  about  all  COTS  and  reuse  software,  firmware,  and  database  compo¬ 
nents  that  require  a  renewable  license.  It  formed  the  basis  for  the  unlimited  licensing  data 
rights  and  requested  the  following  information: 

a.  the  component  name 

b.  a  brief  description 
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c.  the  SI(s)  where  used 

d.  the  license  terms  (single  user,  enterprise,  etc.) 

e.  the  renewal  period 

f.  the  price  for  current  contract  period 

g.  the  option  price  for  unlimited  licensing 

Note:  If  unlimited  licensing  was  not  available,  the  team  asked  the  offeror  to  state  the 
terms  under  which  it  would  be  willing  to  provide  a  long-term  (20  years  following  the 
end  of  the  current  contract  period)  stable  price  for  purchasing  up  to  twice  the  amount  of 
licenses  as  proposed  for  the  current  contract. 

The  Space  Segment  determined  that  the  TMOS  risks  applied  to  the  Space  Segment  and  started 
with  the  final  TMOS  options.  The  Space  Segment  requested  either  the  government-required  data 
rights  or  alternatives.  If  alternatives  were  proposed,  they  were  required  to  include  risk  mitigation 
plans  to  show  that  the  risk  of  not  providing  the  requested  rights  could  be  successfully  mitigated. 

5.3  General  Guidance 

There  are  many  possibilities  for  data  rights  options.  Choose  enough  options  to  ensure  decision 
makers  have  viable  choices  to  ensure  data  rights  can  be  priced  within  contract  constraints.  Also, 
select  a  presentation  style  that  suits  the  audience  and  the  options  being  presented.  A  bulleted  list 
may  be  sufficient  for  some  needs;  others  will  need  tables  like  those  presented  above. 

5.4  Lessons  Learned 

Although  the  formats  used  in  Tables  1-4  can  be  difficult  to  explain  to  an  audience  unfamiliar  with 
matrix  approach  discussed  in  this  paper,  the  authors’  experience  was  that  they  provided  the  most 
effective  presentation  of  the  information. 

One  other  possible  format  is  shown  in  Table  5,  for  the  deployment  options. 
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Table  5:  Alternate  Deployment  Data  Options  View 


TMOS  PO  (A) 


TMOS  Contrac¬ 
tors  (B) 


TSAT  Contrac¬ 
tors  (C) 
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It  may  be  best  to  combine  all  the  risk  areas  into  combined  option  sets  from  the  beginning.  We  did 
not  do  this  for  the  TMOS  options,  but  if  we  had,  it  would  have  been  similar  to  Table  6. 

Table  6:  Combined  Options  View 


Opt  1 

Opt  2 

Opt  3 

Opt  4 

Opt  5 

Opt  6 

Opt  7 

Architectural  Level  Design 

X 

X 

X 

X 

X 

X 

X 

Additional  Design  Info 

X 

X 

X 

X 

X 

Source  Code 

Development  Environment 

X 

X 

X 

Test  Info 

X 

X 

X 

Architectural  Level  Design 

X 

X 

X 

X 

X 

X 

X 

Additional  Design  Info 

X 

X 

X 

X 

X 

X 

X 

Source  Code 

X 

X 

Development  Environment 

X 

X 

Test  Info 

X 

X 

Architectural  Level  Design 

X 

X 

X 

X 

X 

X 

Additional  Design  Info 

X 

X 

X 

X 

Source  Code 

X 

Development  Environment 

Test  Info 

Architectural  Level  Design 

X 

X 

X 

X 

X 

X 

Additional  Design  Info 

X 

X 

Source  Code 

X 

Development  Environment 

Test  Info 

Architectural  Level  Design 

X 

X 

X 

X 

X 

X 

X 

Additional  Design  Info 

X 

X 

X 

X 

X 

X 

X 

Source  Code 

X 

X 

X 

X 

X 

X 

X 

Development  Environment 

X 

X 

X 

X 

X 

X 

X 

Test  Info 

X 

X 

X 

X 

X 

X 

X 

Architectural  Level  Design 

X 

X 

Additional  Design  Info 

X 

X 

Source  Code 

X 

X 

Development  Environment 

X 

X 

Test  Info 

X 

X 
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DoD  AF  Other  TSAT  TMOS  TMOS 

Maintenance  Depot  DoD  Contractors  Contractors  Contractors  PO 

Contractors 


6  Other  Data  Rights-Related  Issues 


There  are  other  data  rights  related  issues  that  might  impact  other  programs.  These  include  the  use 
of  non-modified,  standard  commercial  off-the-shelf  (COTS)  software  (such  as  a  word  processing 
program),  the  use  of  government  off-the-shelf  (GOTS)  software,  the  use  of  free  and  open  source 
software  (FOSS),  and  the  use  of  software  written  in  a  foreign  country  (either  COTS,  GOTS, 
FOSS,  or  newly  developed  code). 

6.1  TMOS  Experience 

TMOS  did  not  specifically  address  any  issues  related  to  COTS,  GOTS,  FOSS,  or  foreign  software 
during  the  source  selection.  The  program  is  working  through  issues  related  to  FOSS. 

6.2  Space  Segment  Experience 

The  Space  Segment  did  address  one  aspect  of  COTS  licenses.  For  non-modified  COTS  that  was 
not  used  for  software  resident  on  the  satellite,  the  offerors  were  asked  to  show  that  the  licenses 
were  in  not  in  conflict  with  any  FAR  provisions.  There  were  no  specific  issues  related  to  GOTS, 
FOSS,  or  foreign  software. 

6.3  General  Guidance 

The  issues  surrounding  non-modified  commercial  off-the-shelf  (COTS),  government  off-the-shelf 
(GOTS)  and  open  source  software  (OSS)  are  slightly  different  than  the  data  issues  discussed 
above. 

6.3.1  Non-Modified  COTS 

For  non-modified  COTS  that  isn’t  used  in  a  safety-critical  or  flight-critical  environment,  the  main 
concern  is  most  likely  related  to  the  standard  license.  Many  standard  COTS  licenses  have  terms 
and  conditions  conflict  with  FAR.  The  government  needs  to  ensure  that  the  prime  contractor  un¬ 
derstands  that  it  will  need  to  negotiate  a  license  that  is  most  likely  different  from  the  standard 
commercial  license  for  that  product.  In  some  instances,  if  a  COTS  product  is  on  the  General  Ser¬ 
vices  Administration  list,  the  license  may  have  already  been  modified. 

There  are  many  other  issues  related  to  the  use  and  maintenance  of  COTS  software,  but  only  data 
rights-related  issues  are  captured  in  this  report. 

6.3.2  Government  Off-The-Shelf  (GOTS) 

Among  the  several  possible  issues  related  to  the  use  of  GOTS  software  are  the  following: 

•  Does  the  government  have  existing  rights  to  the  software?  If  not,  or  if  the  rights  not  appro¬ 
priate,  contractors  that  want  to  use  the  GOTS  product  may  be  unwilling  to  do  so,  fearing  a 
lawsuit.  Therefore,  government  program  offices  must  be  sure  to  get  documentation  of  data 
rights  for  all  software  used  and  developed  for  their  programs. 
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•  If  the  prime  contractor  for  the  program  using  the  GOTS  modifies  the  software  using  private 
funding  (such  as  independent  research  and  development  funds),  then  the  prime  contractor 
may  consider  the  final  product  to  be  proprietary.  The  data  rights  for  these  types  of  modified 
products  should  be  part  of  the  source  selection  process  if  possible.  If  issues  arise  during  con¬ 
tract  execution,  program  management  and  contracting  personnel  need  to  ensure  the  data 
rights  decisions  are  legally  documented. 

6.3.3  Open  Source  Software  (OSS) 

Currently,  open  source  software  is  allowed  in  DoD  systems,  as  long  as  it  passes  all  the  certifica¬ 
tion  testing  required  of  COTS,  GOTS,  and  newly  developed  software.  To  check  for  the  latest  pol¬ 
icy  on  open  source  software  check  the  DoD  Chief  Information  Office  website: 
http://www.defenselink.mil/cio-nii/ 

One  key  issue  to  check  when  using  OSS  is  whether  changes  made  for  use  by  the  program  have  to 
be  submitted  back  to  the  source  of  the  software.  Also,  as  with  COTS,  licenses  must  be  checked 
for  issues  that  are  in  conflict  with  FAR. 

6.4  Lessons  Learned 

Try  to  work  out  as  many  licensing  and  data  rights  issues  as  possible  during  the  source  selection. 
The  government  has  the  most  leverage  at  this  point  in  the  development  cycle.  Be  sure  any  com¬ 
mercial  and  OSS  licenses  do  not  indemnify  the  government  beyond  what  is  allowed  in  FAR  and 
ensure  the  government  understands  what  it  will  have  rights  to. 
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7  GPS  Data  Rights 


7.1  Approach 

The  GPS  program  had  to  deal  with  data  rights  issue  for  both  the  Operational  Control  Segment 
(OCX)  and  GPS  III.  It  took  the  approach  of  asserting  GPR  or  unlimited  rights  for  all  deliverables 
and  instructed  offerors  to  identify  exceptions  together  with  justifications. 

The  GPS  team  identified  the  data  rights  for  each  Contract  Data  Requirements  List  (CDRL)  item. 
The  RFP  included  an  attachment  that  listed  every  CDRL  item  and  a  field  for  the  offeror  to  list  the 
asserted  data  rights  and  any  cost  associated  with  providing  those  rights.  The  government  filled  in 
many  of  these  fields  in  advance.  For  some  CDRL  items  the  government  asserted  that  the  rights 
associated  with  that  CDRL  should  be  available  to  the  U.S.  government  at  no  cost  (for  example, 
the  software  transition  plan  and  the  software  requirements  specification). 

Some  CDRLS,  such  as  the  cost-related  CDRLs  and  measurement  report  CDRL,  did  not  contain 
technical  data  or  computer  software. 

In  many  instances  the  government  asserted  unlimited  data  rights  in  the  RFP  attachment,  but  in 
some  instances  it  left  that  field  blank,  to  be  supplied  by  the  contractor.  In  many  cases  the  cost 
field  was  also  left  blank  to  be  supplied  by  the  contractor. 

Attention  was  paid  to  the  difference  between  technical  data  and  software:  Two  entries  were  pro¬ 
vided  for  some  of  the  CDRLs,  one  for  technical  data  and  one  for  software.  This  was  done  for  the 
software  product  specification,  the  data  accession  list,  and  the  CDRL  for  the  modeling  and  simu¬ 
lation  report. 

7.2  General  Guidance 

Depending  on  a  program’s  concerns  regarding  rights  for  commercial  software,  the  GPS  example 
may  provide  a  workable  approach.  The  program  should  carefully  examine  the  CDRL  list  to  identi¬ 
fy  any  that  contain  technical  data,  software,  or  both — and  determine  what  rights  the  government 
should  request. 

7.3  Lessons  Learned 

Programs  need  to  ensure  it  is  clear  what  constitutes  software,  as  opposed  to  technical  data.  Items 
such  as  test  cases,  build  scripts,  development  environment  information,  and  the  like  could  be 
missed  if  the  technical  data  and  software -related  data  are  not  well  defined. 


31  |  CMU/SEI-201 0-TN-01 4 


8  Risk  Ratings 


This  section  discusses  how  the  TMOS  program  developed  the  data  rights  options  used  on  that 
program.  It  was  done  using  a  risk-based  approach  that  is  described  below.  If  a  program  needs  spe¬ 
cialized  data  rights,  the  process  may  prove  helpful  in  determining  them. 

8.1  TMOS  Experience 

After  working  out  the  various  options  as  discussed  in  Section  5.1,  the  TMOS  team  next  tried  to 
plot  these  options  on  a  5x5  risk  scale.  The  “consequence”  axis  is  related  to  the  consequences  if  the 
data  rights  included  in  that  particular  option  were  not  provided  and  the  “probability”  axis  related 
to  the  probability  of  having  those  unwanted  consequences  due  to  not  having  the  needed  data 
rights.  The  probabilities  and  impacts  were  determined  based  on  discussions  with  a  small  team  of 
subject  matter  experts.  The  final  product,  based  on  paragraphs  4.1.1-  4.1.4  can  be  seen  in  Figure 
1. 

(x)  Development  Options 
Sustainment  Options 
(x)  Interoperability  Options 
(x)  Deployment  Options 


Figure  1:  Data  Options  Risk  Matrix 
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This  matrix  was  used  to  help  reduce  the  options.  From  the  risk  matrix  above  and  tables  in  Section 
5.1  it  can  be  seen  that  the  risks  decrease: 

•  As  more  data  is  provided  to  the  other  TMOS  contractors  and  the  TSAT  contractors  (Table  2, 
Option  7  vs.  Option  1) 

•  As  more  data  is  provided  to  the  AF  Depot  and  the  maintenance  contractors  (Table  3.  Option 
2  vs.  Option  1) 

•  As  more  data  is  provided  to  the  other  (interfacing  or  follow-on)  DoD  contractors  (Table  4, 
Options  3  vs.  Option  1) 


TMOS  selected  the  two  options  shown  in  Table  6  to  provide  the  offerors  for  costing: 
Table  7:  TMOS  Selected  Options 


Development  Option 

Sustainment  Option 

Interoperability  Option 

Deployment  Option 

Moderate  Risk 

3 

1 

2 

1 

Low  Risk 

6 

2 

3 

1 

These  options  equate  to  the  following  risk  options: 

Moderate  Risk  Option 

.  TMOS  SPO 

-  Top-Level  Design  -  Detailed  Design 

•  TMOS  Contractor  Team 

-  Top-Level  Design  -  Detailed  Design 

•  TSAT  Contractors  (Space,  Terminals,  GIG) 

-  Top-Level  Design 

•  Air  Force  Depot 

-  Top-Level  Design  -  Detailed  Design 

-  Source  Code  -  Development  Environment 

-  Test  Information  -  Unlimited  Licenses 

•  DoD  Contractors  for  Maintenance  Competition  (under  specific  conditions) 

-  NA 

•  Other  DoD  Contractors  (other  programs,  as  needed) 

-  Top-Level  Design 

Low  Risk  Option: 

.  TMOS  SPO 

-  Top-Level  Design  -  Detailed  Design 

-  Source  Code  -  Test  Information 

-  Unlimited  Licenses 
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•  TMOS  Contractor  Team 

-  Top-Level  Design 

-  Source  Code 

-  Test  Information 

-  Detailed  Design 

-  Development  Environment 

•  TSAT  Contractors  (Space,  Terminals,  GIG) 

-  Top-Level  Design 

-  Detailed  Design 

•  Air  Force  Depot 

-  Top-Level  Design 

-  Detailed  Design 

-  Source  Code 

-  Development  Environment 

-  Test  Information 

-  Unlimited  Licenses 

•  DoD  Contractors  for  Maintenance  Competition  (under  specific  conditions) 

-  Top-Level  Design 

-  Detailed  Design 

-  Source  Code 

-  Development  Environment 

-  Test  Information 

-  Unlimited  Licenses 

•  Other  DoD  Contractors  (other  programs,  as  needed) 


-  Top-Level  Design  -  Detailed  Design 

8.2  Space  Segment  Experience 

The  Space  Segment  team  decided  to  simplify  the  data  rights  and  asked  for  the  low-risk  TMOS 
data  set.  The  offerors  were  asked  to  bid  the  cost  of  that  data  set.  They  were  provided  an  alterna¬ 
tive,  which  was  to  bid  something  other  than  the  required  data  set  and  provide  a  risk  mitigation 
plan. 

8.3  General  Guidance 

There  are  many  ways  to  condense  the  options  into  manageable  sets.  A  small  set  of  options  may 
just  be  labeled  low,  moderate,  and  high  risk  without  using  a  risk  matrix.  Or,  start  with  the  most 
important  data  sets  and  users  and  label  the  most  desired  combination  as  low  risk,  and  work  out  the 
remainder  of  the  options  from  there.  It  is  recommended  that  the  option  set  be  reduced  to  three  op¬ 
tions  at  most.  Using  one  data  set,  as  was  done  for  the  Space  Segment,  can  work  well  and  be  much 
easier  to  explain  and  evaluate. 

8.4  Lessons  Learned 

The  TMOS  program  presented  the  entire  data  set  to  a  very  limited  audience  of  decision  makers 
who  were  very  familiar  with  the  issues.  It  was  fairly  difficult  to  explain.  The  low  and  moderate 
data  set  options  were  presented  to  a  larger  audience,  including  high-level  officers  who  were  in¬ 
volved  in  program  oversight;  presenting  just  these  two  options  was  much  easier.  The  larger  au¬ 
dience  did  not  ask  detailed  questions  that  required  explaining  the  larger  data  sets. 
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If  the  team  can  decide  on  one  specific  set  of  rights  that  the  government  feels  are  required  on  the 
program,  then  just  ask  for  those  specific  rights.  It  is  easier  to  evaluate  one  option  rather  than  sev¬ 
eral.  The  Space  Segment  team  used  lessons  learned  from  the  TMOS  experience  and  decided  to 
use  just  the  option  that  was  selected  on  TMOS,  since  it  was  sufficient  to  meet  its  needs.  This  also 
provided  continuity  across  the  program  and  made  it  easier  to  explain  what  Space  Segment  data 
rights  were  being  sought.  Already  having  that  data  set  in  place  for  TMOS  also  helped  with  the 
justification  of  why  the  data  rights  were  being  requested. 
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9  Contract  Clauses 


After  determining  the  risk(s)  appropriate  to  the  program,  the  next  step  is  to  translate  that  informa¬ 
tion  into  contract  clauses.  The  best  time  to  do  this  is  during  the  source  selection.  This  should  be 
included  in  the  RFP  and  can  even  be  used  as  a  selection  criterion.  If  the  team  is  negotiating  data 
rights  for  a  contract  that  has  already  been  awarded,  the  same  principles  apply. 

9.1  TMOS  Experience 

The  first  step  is  to  determine  what  to  ask  for.  For  TMOS,  this  was  determined  by  using  the  risk 
process  and  deciding  to  ask  for  costs  for  the  low-  and  medium-risk  data  sets.  The  TMOS  program 
decided  to  ask  for  separate  price  information  for  each  data  set  for  both  low  and  medium  risk.  This 
resulted  in  asking  for  prices  for  six  different  data  sets.  The  responses  were  then  evaluated  as  part 
of  the  normal  source  selection  process. 

The  TMOS  contract  had  two  options  contract  line  item  numbers  (CLINs):  one  for  the  delivery  of 
the  licensing  rights  and  a  second  for  the  data  rights.  Because  TMOS  was  a  software-based  devel¬ 
opment.  there  were  no  hardware  data  rights  issues. 

9.2  Space  Segment  Experience 

The  Space  Segment  bundled  all  the  data  sets  together  and  asked  offerors  to  cost  those  specific 
rights  or  provide  an  alternative  with  risk  mitigation.  The  risk  mitigation  option  allowed  offerors  to 
propose  an  alternative  if  they  felt  it  wasn’t  feasible  to  provide  the  requested  data  rights.  If  risk 
mitigation  plans  were  provided,  the  government  analyzed  the  risks  associated  with  the  mitigation 
plans  very  carefully  and  considered  that  as  part  of  the  overall  evaluation.  The  approach  is  much 
easier  than  others,  but  may  not  work  in  all  situations.  The  Space  Segment  team  also  included 
some  very  specific  language  regarding  flight  software.  If  a  system  has  any  critical  software,  the 
program  may  want  to  consider  special  provisions  for  that  software. 

The  Space  Segment  team  used  a  combination  of  an  H  clause,  Section  L  and  M  language,  a  con¬ 
tract  attachment  regarding  data  rights,  and  options  CLINs  for  data  rights  and  licensing  delivery. 
The  contract  attachment  included  language  to  the  effect  that  the  data  rights  were  separable  from 
the  current  contract,  non-severable,  and  would  remain  in  effect  throughout  the  life  of  the  system. 
The  Space  Segment  team  also  made  sure  that  any  data  rights  to  software  provided  by  a  subcon¬ 
tractor  were  transferable  to  the  government.  Ensuring  the  data  rights  remain  in  effect  throughout 
the  life  of  the  system  is  important  because  most  development  contracts  end  before  system  end-of- 
life  and  the  government  may  need  to  invoke  the  data  rights  to  ensure  the  software  is  properly 
maintained.  Transfer  from  a  subcontractor  is  also  important.  Generally,  the  government  has  no 
privity  of  contract  with  a  subcontractor,  but  in  the  case  of  data  rights,  those  rights  would  need  to 
be  transferred  to  the  government  at  the  end  of  the  contract. 

9.3  GPS  Experience 

The  GPS  program  included  an  Attachment  6  which  listed  all  the  CDRLs  with  instructions  for  the 
offerors  to  fill  in  the  blank  areas.  It  also  used  a  Section  K  which  contained  the  information  from 
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DFARS  252.227-7017,  Identification  and  Assertion  of  Use,  Release,  or  Disclosure  Restrictions. 
Section  L  of  the  RFP  included  the  request  that  Section  K  identify  what,  if  any,  restrictions  on  the 
government’s  rights  to  use,  release  or  disclose  the  technical  data  or  computer  software  would  exist 
for  each  and  every  CDRL  to  be  delivered  under  the  contract.  Section  M  included  a  criterion  for 
the  government  to  evaluate  the  extent  to  which  the  offeror  was  willing  to  provide  or  sell  to  the 
government  no  less  than  unlimited  rights  to  all  technical  data  labeled  as  such  in  column  4  of  the 
table  in  Attachment  6,  and  Government  Purpose  Rights  to  all  remaining  technical  data  and  com¬ 
puter  software  delivered  under  this  contract  as  indicated  in  the  offeror’s  completed  Attachment  6 
and  its  completed  Section  K  certification. 

The  instructions  for  completing  Attachment  6  included  instructions  for  how  to  respond  if  there 
were  valid  reasons  why  an  offeror  had  to  develop  entirely  at  private  expense  or  provide  previously 
developed  technical  data  or  computer  software  under  the  contract.  GPS  also  include  a  firm  fixed 
price  CLIN  for  rights  in  technical  data,  computer  software,  and  computer  software  documentation. 

9.4  General  Guidance 

Consider  using  an  H  clause  if  there  are  circumstances  that  require  special  provision  such  as  satel¬ 
lite  or  safety-critical  software.  Think  about  all  options  when  determining  the  path  forward  with 
respect  to  contract  clauses  for  data  rights.  The  TSAT  program  used  a  combination  of  an  H  clause, 
a  contract  attachment  on  data  rights,  and  data  rights  CLINs.  GPS  used  an  RFP  attachment,  a  CLIN 
and  a  K  clause.  There  are  also  standard  FAR  clauses  that  can  be  used  if  they  are  appropriate  for 
the  program.  Be  sure  to  start  to  work  with  the  contract  personnel  early  in  the  RFP  process  to  en¬ 
sure  the  data  rights  language  is  correct. 

9.5  Lessons  Learned 

There  are  three  main  lessons  learned  with  respect  to  contract  clauses: 

(1)  Consider  all  the  options,  including  H  clause,  contract  attachments,  standard  FAR  clauses, 
and  CLINs. 

(2)  Consider  the  feasibility  of  basing  the  data  rights  on  the  CDRL  items. 

(3)  Ensure  both  the  prime  and  subcontractors  are  appropriately  covered  such  that  the  govern¬ 
ment  will  have  the  needed  rights  until  the  end-of-life  of  the  program. 

(4)  Ensure  CLINs  are  included  such  that  the  government  can  “take  delivery”  of  the  data  rights. 
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10  Conclusion 


Data  rights  can  be  a  very  confusing  area  for  many  programs.  The  government  must  balance  risk  to 
the  program  with  the  cost  and  schedule  advantages  that  may  arise  from  using  software  from  a 
commercial  vendor.  There  are  many  factors  to  consider  when  determining  the  data  rights  needed 
for  a  project.  Take  into  consideration  the  various  risks  during  development,  deployment  and  sus¬ 
tainment  as  well  as  licensing  risks.  Also,  consider  the  most  likely  sources  of  software  on  the 
project. 

If  all  the  software  is  developed  using  government  funding,  then  the  standard  FAR  clauses  may  be 
sufficient.  If  there  is  a  mixture  of  development,  modification  of  commercial  software,  COTS, 
GOTS,  and  OSS,  then  specialized  data  rights  may  be  required.  The  best  time  to  tackle  these  issues 
is  while  writing  the  RFP.  Determine  what  contract  clauses  are  needed  and  if  data  rights  will  be 
included  in  Section  L  and  M  as  a  criteria  for  award.  Finally,  ensuring  the  correct  clauses  and 
CLINs  are  on  contract  is  extremely  important.  Any  changes  that  might  affect  data  rights  that  are 
made  during  contract  execution  must  include  the  appropriate  changes  to  the  data  right  contract 
language. 

The  investment  of  time  and  careful  consideration  of  data  rights  at  the  beginning  of  the  RFP 
processes  should  pay  off  with  appropriate  data  rights  (and  lower  government  risks)  on  a  program. 
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11  Useful  Sources 

This  section  lists  additional  references  that  may  be  helpful 
issues. 

Table  8:  Useful  Sources 

in  understanding  software  data  rights 

Name 

Author 

Description 

Link 

“Acquiring  All  That  You 
Need  to  Maintain  Your 
Software”  [ACC] 

Art  Samora 

An  article  on  the 
acquisition  of  software 
and  licensing  rights  from 
Defense  AT&L  magazine 
(U.S.  Navy) 

http://www.dau.mil/pubs/dam/03_04_2005/kan- 

ma05.pdf 

Intellectual  Property: 
Navigating  Through 
Commercial  Waters 

OUSD 

(AT&L) 

The  report  discusses 
issues  and  solutions  for 
dealing  with  intellectual 
property  rights.  Version 

1.1,  October  15,  2001. 

http://www.acq.osd.mil/dpap/Docs/intelprop.pdf 

Army  ASA(ALT)  Memo: 
"Data  Management  and 
Technical  Data  Rights” 

SAAL-PA 

Directs  immediate 
implementation  of  USD 
(AT&L)  July  19,  2007 
memorandum  (“Data 
Management  Strategy”) 
on  all  Army  ACAT  1  and  II 
programs.  Application  to 
ACAT  III  programs  is 
strongly  encouraged. 

https  ://acc.dau.mil/CommunityBrowser.aspx?id= 
206953 

GAO  Report  GAO-06- 
839;  DoD  Should  Streng¬ 
then  Policies  for  Assess¬ 
ing  Technical  Data  Needs 
to  Support  Weapon  Sys¬ 
tems  (July  2006) 

GAO 

Although  this  report  does 
not  focus  on  software,  it 
does  address  data  rights 
in  general. 

http://www.gao.gov/cgi-bin/getrpt7GAO-06-839 

Public  Law  109-364. 

H.R.  5122/P. L.  109-364, 
John  Warner  National 
Defense  Authorization  Act 
for  the  Financial  Year 

2007 

N/A 

Includes  Subtitle  A — 
Provisions  Relating  to 

Major  Defense  Acquisition 
Programs  SEC.  802. 
ADDITIONAL 
REQUIREMENTS 
RELATING  TO 
TECHNICAL  DATA 
RIGHTS. 

http://frwebgate.access.gpo.gov/cgi- 
bin/getdoc.cgi?dbname=109_cong_reports&doci 
d=f:hr702. 109.pdf 

DAU  Site  with  data  rights  language: 

https  ://acc.dau.mil/CommunityBrowser.aspx?id= 

1 23330&lang=en-US 

Data  Management  and 

USD 

USD(ATL)  July  2007 

https  ://acc.dau.mil/GetAttachment.aspx?id=1 589 

Technical  Data  Rights 
Memorandum 

(AT&L) 

memo  pertaining  to  the 
requirement  for  ACAT  1 
and  II  programs  to  employ 
data  management 
systems  that  address  the 
program's  assessment  of 
system  life-cycle  technical 
data  needs 

1 6&pname=file&aid=2961 2&lang=en-US 
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